In the early days of modern computing, the large size and cost of computers tended to result in a concentration of computer equipment in large data centers. Most commercial users of computers would have paid one or more data center operators to perform their computing tasks. Over the past decades, miniaturization and cost decreases have driven a trend toward more commercial computer users owning and operating their own computer systems. This trend is not universal, however.
One exception includes those computer users whose computing needs are particularly massive and/or require exceptional reliability, redundancy or security. Examples of such users include very large corporations, and especially financial sector corporations such as banks, exchanges, brokerages and the like. These types of corporations will often contract with third-party providers to supply their computing needs.
The preeminent example of a third party provider of computing services is the International Business Machines (IBM) Corporation. IBM has several thousand users who pay for the capability and reliability of its System z (“z” standing for “zero downtime”) computing platform. The way users rely on the performance of the workload on the System z platform is illustrative background for the present invention's system and method for managing computer usage.
Each group of logically-related computing functions being performed for a user is referred to as a logical partition (LPAR). The workload within each LPAR is divided up into logical entities called Regions (Jobsteps or Started Task); for example, running specific reports, running a set of online transactions, running data base back-ups, etc. Each of the Regions is allocated to a Service Class. Within each Service Class the workload is allocated to one of multiple workload importance levels, e.g. the first part of the workload to a high class but the longer the workload takes to execute, the lower the workload importance level gets.
Service Class settings need to be reviewed and adjusted in a permanent process to the ever changing workload requirements. The performance of the workload on the System z platform is determined by several factors, but most significant are the service class and capacity limitations using DC and GCL and/or hardware limitations. The present inventors have developed systems and methods for managing computer system usage based on the time criticality of workload, an example of which is described in U.S. patent application Ser. No. 14/199,364, filed on Mar. 6, 2014 (U.S. Pat. No. 9,038,090), Ser. No. 14/310,062, filed on Dec. 2, 2014 (U.S. Pat. No. 8,904,405), Ser. No. 14/714,990, filed on May 18, 2015, the contents of which applications are herein incorporated by reference in their entirety.
To gather usage and other data used in the execution of such systems and methods, the present inventors have made use of WLM (Workload Manager), which is an integrated part of the System z software. For reporting and accounting purposes, it is also possible to assign Report Classes to a singular item (e.g. a transaction), a group of items, a region or a group of regions, which each may be assigned to different Service Classes. Thus, a report class is an item of work for which z/OS Workload Manager reports usage data. By default, usage data is reported as total for each service class.
It is also important to consider that the cost to use the System z platform is determined by several factors, but a significant recurring cost for almost every user is the monthly license charge (MLC). This charge is applied for usage of proprietary IBM products that are used in connection with System z, such as the operating system (z/OS), information management system (IMS), customer information control system (CICS), relational database (DB2) and the like.
Generally, the MLC varies depending upon the usage of the IBM products during the billing period (i.e., 2nd of month at 0:00 until 1st of following month at 24:00). More particularly, product usage is measured in millions of service units (MSU), and the MLC is determined based on the highest average MSU usage of any full 4 hour period within the billing period (referred to as Rolling 4 Hr Average Usage or R4HA). Thus, controlling the MLC involves, in large part, controlling peak MSU usage.
Reports of usage are stored in many different types of records. These records are created by the System Measurement Facility (SMF) and are thus called SMF records. Each type of SMF record reporting some different aspect of system usage, such as transaction usage, data base usage, number of I/O, usage of storage, etc.
Complicating matters, the billing methods previously used would charge one rate for all workload within one LPAR, With the introduction of new pricing methods, it is now possible to run workloads with different rates on one LPAR, with some of the workload charged at a base rate and other workload on the same LPAR charged at a completely different rate (e.g., with a high discount). Examples of this in the context of IBM's System z include “Mobile Workload Pricing” (MWP) and “Collocated Application Pricing.” it is even possible that within one Region, different workloads are charged at different rates (e.g., with region CICS, some transactions are discount-eligible and others are not). However, all workload usages are still shown in MSUs, with no real-time pricing distinction. The result is that the real time MSU usage that is shown by existing software may not realistically reflect the MSU usage that will be invoiced: the real time Rolling 4 Hour Average MSU usage may not represent the billable MSU usage.
Customers that can prove that discount eligible workload used certain MSU capacity (e.g., via Service Class or Reporting Class usage reporting) will get a discount to their MLC prices, which is calculated at the end of a billing period. For reference purposes herein, “gross usage” is the value of the used capacity without taking any discounts into consideration, “billable usage” is an effective capacity usage taking into account discounts. As noted, in real time throughout a billing period, only gross MSU usage is shown. However, this figure therefore only represents the maximum billable MSU usage, but not necessarily the real billable. MSU usage.